Just Call Me Internet

home *** CD-ROM | disk | FTP | other *** search

/ Just Call Me Internet / Just Call Me Internet.iso / docs / ascii / internet / nhelp411 / tcp < prev next >

Wrap

Text File | 1991-09-18 | 13.3 KB | 286 lines

=== NOSview [137] tcp === The 'tcp' commands are used for the Transmission Control Protocol (TCP) service. _________________________________________________________________ tcp irtt [<milliseconds>] Default: 5000 _________________________________________________________________ Display or set the initial-round-trip-time (IRTT) estimate, to be used for new TCP connections until they can measure and adapt to the actual value. Increasing the value of IRTT when operating over slow channels will avoid the flurry of retransmissions that would otherwise occur as the smoothed estimate settles down at the correct value. Note that this command should be given before servers are started in order for it to have effect on incoming connections. TCP also keeps a cache of measured round trip times and mean deviations (MDEV) for current and recent destinations. Whenever a new TCP connection is opened, the system first looks in this cache. If the destination is found, the cached IRTT and MDEV values are used. If not, the default IRTT value mentioned above is used, along with a MDEV of 0. This feature is fully automatic, and it can improve performance greatly when a series of connections are opened and closed to a given destination (e.g. a series of FTP file transfers or directory listings). >> Example: tcp irtt 5000 _________________________________________________________________ tcp kick <&TCB> _________________________________________________________________ If there is unacknowledged data on the send queue of the specified Transmission Control Block (TCB), this command forces an immediate retransmission. The TCB address <&TCB> can be determined from the 'tcp status' command. >> Example: tcp kick 83360008 _________________________________________________________________ tcp mss [<bytes>] Default: 512 _________________________________________________________________ Display or set the TCP Maximum Segment Size (MSS). MSS is parameter that limits the amount of data that the remote TCP will send in a single TCP packet. MSS values are exchanged in the SYN (connection request) packets that open a TCP connection. In the NOS implementation of TCP, the MSS actually used by TCP is further reduced in order to avoid fragmentation at the local IP interface. That is, the local TCP asks IP for the MTU of the interface that will be used to reach the destination. It then subtracts 40 from the MTU value to allow for the overhead of the TCP and IP headers. If the result is less than the MSS received from the remote TCP, it is used instead. The setting of this TCP-level parameter is somewhat less critical than the IP MTU and AX.25 <paclen> parameters, mainly because it is automatically lowered according to the MTU of the local interface when a connection is created, as described above. Although this is, strictly speaking, a protocol layering violation (TCP is not supposed to have any knowledge of the workings of lower layers) this technique does work well in practice. However, it can be fooled; for example, if a routing change occurs after the connection has been opened and the new local interface has a smaller MTU than the previous one, IP fragmentation may occur in the local system. The only drawback to setting a large MSS is that it might cause avoidable fragmentation at some other point within the network path if it includes a "bottleneck" subnet with an MTU smaller than that of the local interface. (Unfortunately, there is presently no way to know when this is the case. There is ongoing work within the Internet Engineering Task Force on an "MTU Discovery" procedure to determine the largest datagram that may be sent over a given path without fragmentation, but this work is not yet complete). Also, since the MSS you specify is sent to the remote system, and not all other TCPs do the MSS-lowering procedure yet, this might cause the remote system to generate IP fragments unnecessarily. On the other hand, a too-small MSS can result in a considerable performance loss, especially when operating over fast LANs and networks that can handle larger packets. So the best value for MSS is probably 40 less than the largest MTU on your system, with the 40-byte margin allowing for the TCP and IP headers. For example, if you have a SLIP interface with a 1006 byte MTU and an Ethernet interface with a 1500 byte MTU, set MSS to 1460 bytes. This allows you to receive maximum-sized Ethernet packets, assuming the path to your system does not have any bottleneck subnets with smaller MTUs. An MSS of 216 corresponds to the MTU of 256 set up in AX.25 'attach' commands. Changing MSS affects only future connections; existing connections are unaffected. >> Examples: tcp mss 216 (for an AX.25-only system) tcp mss 966 (for a SLIP system) tcp mss 1460 (for an Ethernet or PPP system) _________________________________________________________________ tcp reset <&TCB> _________________________________________________________________ Deletes the TCP control block at the specified address <&TCB>. >> Example: tcp reset 83360008 _________________________________________________________________ tcp rtt <&TCB> <milliseconds> _________________________________________________________________ Replaces the automatically computed round-trip-time in the specified TCB with the rtt in milliseconds. This command is useful to speed up recovery from a series of lost packets since it provides a manual bypass around the normal backoff retransmission timing mechanisms. >> Example: tcp rtt 83360008 3000 _________________________________________________________________ tcp status [<&TCB>] _________________________________________________________________ Without arguments, displays several TCP-level statistics, plus a summary of all existing TCP connections, including TCB address, send and receive queue sizes, local and remote sockets, and connection state. If <&TCB> is specified, a more detailed dump of the specified TCB is generated, including send and receive sequence numbers and timer information. >> Example of 'tnc status' output: ............................................................... : : :( 1)tcpRtoAlgorithm 4 ( 2)tcpRtoMin 0: :( 3)tcpRtoMax 4294967295 ( 4)tcpMaxConn 4294967295: :( 5)tcpActiveOpens 2 ( 6)tcpPassiveOpens 2: :( 7)tcpAttemptFails 0 ( 8)tcpEstabResets 0: :( 9)tcpCurrEstab 4 (10)tcpInSegs 10: :(11)tcpOutSegs 10 (12)tcpRetransSegs 0: :(14)tcpInErrs 0 (15)tcpOutRsts 0: : : : &TCB Rcv Snd Local socket Remote socket State : : Q Q : :858c0008 0 0 ns9bob:ftp ns9ken:1025 Established : :85050008 0 0 ns9bob:1025 ns9liz:ftp Established : :841f0008 0 0 0.0.0.0:ftp 0.0.0.0:0 Listen (S) : :83360008 0 0 ns9bob:telnet ns9liz:1024 Established : :7d530008 0 0 ns9bob:1024 ns9jim:telnet Established : :840d0008 0 0 0.0.0.0:telnet 0.0.0.0:0 Listen (S) : :845b0008 0 0 0.0.0.0:ttylink 0.0.0.0:0 Listen (S) : :84400008 0 0 0.0.0.0:finger 0.0.0.0:0 Listen (S) : :84310008 0 0 0.0.0.0:smtp 0.0.0.0:0 Listen (S) : :83fb0008 0 0 0.0.0.0:discard 0.0.0.0:0 Listen (S) : :83ec0008 0 0 0.0.0.0:echo 0.0.0.0:0 Listen (S) : :.............................................................: >> Example of 'tcp status 83360008' output: ............................................................... :Local: ns9bob:telnet Remote: ns9liz:1024 State: Established : : Init seq Unack Next Re- CW Thrsh Wind MSS Q Total : : sent ind : :Send: 2b66000 2b66026 2b66026 0 216 65535 216 216 0 37 : :Recv: 2b66000 2b66001 0 216 0 0 : :Timer stopped SRTT 49779 ms Mean dev 26384 ms : :.............................................................: _________________________________________________________________ tcp syndata [on|off] Default: off _________________________________________________________________ Display or set the "syndata" flag. When set to 'on', SYN and data are piggybacked. This reduces transmission time, as the sending end does not have to wait for an acknowledgement to the SYN before sending data. >> Example: tcp syndata on _________________________________________________________________ tcp timertype [linear|exponential] _________________________________________________________________ The TCP timer backoff can be either linear or binary exponential. Linear backoff is recommended for amateur radio work. >> Example: tcp timertype linear _________________________________________________________________ tcp trace [on|off] Default: off _________________________________________________________________ Display or set TCP trace mode. When set to 'on', task control block activity is displayed, together with numbered TCP protocol messages. >> Example: tcp trace on ftp ns9aaa produces an output of the form: ............................................................... : : :TCB 862b0008 Closed -> SYN sent : :TCB 89d90008 Listen -> SYN received : :Resolving ns9aaa... Trying ns9aaa:ftp... : :TCB 862b0008 SYN sent -> Established : :FTP session 3 connected to ns9aaa : :TCB 89d90008 SYN received -> Established : :220 ns9aaa FTP version 910618 (PA0GRI v1.7a) ready .... : :Enter user name: helen : :331 Enter PASS command : :Password: : :230 Logged in : :ftp> pwd : :257 "/nos/public" is current directory : :.............................................................: _________________________________________________________________ tcp window [<bytes>] Default: 2048 _________________________________________________________________ Displays or sets the default receive window size. This is a TCP- level parameter that controls how much data the local TCP will allow the remote TCP to send before it must stop and wait for an acknowledgement. If the window size is twice as big as the Maximum Segment Size (MSS), for example, there will be two active packets on the channel at any given time. Large values of window size provide improved throughput on full-duplex links, but are a problem on the air. The actual window value used by TCP when deciding how much more data to send is referred to as the effective window. This is the smaller of two values: the window advertised by the remote TCP minus the unacknowledged data in flight, and the congestion window, an automatically computed time-varying estimate of how much data the network can handle. In most cases it is safe to set the TCP window to a small integer multiple of the MSS (e.g. 4 times), or larger if necessary to fully utilize a high bandwidth*delay product path. One thing to keep in mind, however, is that advertising a certain TCP window value declares that the system has that much buffer space available for incoming data. NOS does not actually preallocate this space; it keeps it in a common pool and may well "overbook" it, exploiting the fact that many TCP connections are idle for long periods and gambling that most applications will read incoming data from an active connection as soon as it arrives, thereby quickly freeing the buffer memory. However, it is possible to run NOS out of memory if excessive TCP window sizes are advertised and either the applications go to sleep indefinitely (e.g. suspended Telnet sessions) or a lot of out-of-sequence data arrives. It is wise to keep an eye on the amount of available memory and to decrease the TCP window size (or limit the number of simultaneous connections) if it gets too low. Depending on the channel access method and link level protocol, the use of a window setting that exceeds the MSS may cause an increase in channel collisions. In particular, collisions between data packets and returning acknowledgements during a bulk file transfer may become common. Although this is, strictly speaking, not TCP's fault, it is possible to work around the problem at the TCP level by decreasing the window so that the protocol operates in stop-and-wait mode. This is done by making the window value equal to the MSS. In summary, therefore, keep MSS <= window <= 2*MSS for half- duplex radio links. >> Example: tcp window 216